1. Field of the Invention
The present invention relates generally to Hypertext Transfer Protocol (HTTP)/Transmission Control Protocol (TCP)-based multimedia service, and more particularly, to an apparatus and method for ensuring service quality in HTTP/TCP-based multimedia service.
2. Description of the Related Art
In HTTP-based multimedia service, data is transmitted and received between a client and a server by exchanging a content request (HTTP GET) with a response (HTTP Response) to the content request. When the client initially accesses the server, the server transmits a serviceable content list and a Media Presentation Description (MPD) for media content to the client. The MPD describes information required for the client to receive the media content, such as the type of the media content, the average bit rate of the media content, and the Uniform Resource Identifiers (URIs) or Uniform Resource Locators (URLs) of content Segments covering a time unit. The client repeatedly requests necessary content based on the MPD.
Clients differ as to their terminals and network situations. To meet service requirements of clients of various terminals in various networks, the server may have coded streams with different quality levels for the same content. Therefore, a client may request a stream with an appropriate quality to the server according to its terminal or network state, thereby enabling a seamless service.
The MPD segments a media stream on a time unit basis. Thus, each time a client requests media content, the client selects one of stream segments in the same time zone according to its situation and transmits an HTTP GET for the selected stream segment to the server. In response to the client request, the server transmits the stream segment together with a response message header (with status code 200 OK).
If the response message is too large, the server transmits the response message separately in one or more TCP packets. Upon successful receipt of all TCP packets, the client reconstructs the original HTTP response message with the TCP packets.
TCP adopts Automatic Repeat reQuest (ARQ) to ensure the reliability of data transmission and reception. According to ARQ, when a transmitter receives a response message indicating detection of an error in received data, that is, a Negative ACKnowledgment (NACK) message from a receiver, or fails to receive any response message within a predetermined time from the receiver, the transmitter automatically retransmits data to the receiver. Therefore, transmission reliability can be ensured for every TCP-based service, such as an HTTP or File Transfer Protocol (FTP) service.
If any of the TCP packets is lost or erroneous, the TCP packet is retransmitted until it is successfully received. In this manner, TCP-based services such as HTTP or FTP services achieve transmission reliability.
However, when a TCP packet is lost due to congestion or interference during data transmission or retransmission, unreliability occurs frequently at the TCP layer because of errors or a poor channel state, an end-to-end transmission delay becomes excessive.
Moreover, if the network state is poor and the size of transmission data at the HTTP layer is large, the end-to-end transmission delay becomes excessive and compromises service quality for a delay-sensitive service such as multimedia service.
FIG. 1 illustrates a data transmission and reception operation at the HTTP layer (in the upper diagram) and a data transmission and reception operation at the TCP layer (in the lower diagram), according to the prior art.
In the upper diagram of FIG. 1, a server responds to a request received from a client at the HTTP layer. Only when the client completely receives a response message (with status code 200 OK) from the server, may the client process the response message.
In the lower diagram of FIG. 1, the server transmits the response message separately in TCP packets to the client at the TCP layer. Upon generation of an error or data loss during transmission, an erroneous or lost TCP packet is retransmitted. As this operation is repeated until all TCP packets are successfully transmitted, a transmission delay is caused. In addition, when data loss occurs, the resulting decreased transmission rate also leads to a transmission delay.
In a conventional HTTP-based media streaming service, a stream is segmented on a time basis and a stream segment requested by a client is delivered to the client. Therefore, it becomes difficult to reduce an initial buffering delay.
TCP also adopts a slow start method for flow control. According to the slow start method, upon generation of data loss during data transmission at a gradually increased bit rate, the bit rate is reduced significantly and then data is transmitted at the low bit rate. Since an available bit rate cannot be fully utilized in wireless communication experiencing the aforementioned data loss, the slow start method significantly decreases system efficiency.